Collection of Internet/Collection of Internet.iso/infosrvr/doc/www_talk.arc/[e-mail] _Wed Jun 24 18:00:30 1992.msg

Internet Message Format | 1992-11-30 | 6KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA28723; Wed, 24 Jun 92 18:00:30 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
    id AA03892; Wed, 24 Jun 92 18:00:54 +0200
Received: by willow.tc.cornell.edu (4.1/SMI-4.1)
    id AA13181; Wed, 24 Jun 92 12:02:25 EDT
Date: Wed, 24 Jun 92 12:02:25 EDT
From: [e-mail] (Jim Davis)
Message-Id: <[e-mail]>
To: [e-mail]
Subject:  Raisch's Attention link
Cc:
Mime-Version: 1.0
Content-Type:  text/richtext
Content-Transfer-Encoding:  7bit

<paragraph>
In a previous message, R. Raisch proposed a number of interesting
link types.  One of them was the attention link, which I want to
discuss here.  I am uncertain about the need for this link, the
technical ability to provide it, and the definition.

<nl>
<paragraph>
Let me discuss the function first.  The function seems to be
providing a means of notifying an "owner" of a document when certain
conditions obtain.  The conditions Raisch mentions are:<nl>
<indent>
 1) someone has read the document<nl>
 2) someone has modified the document<nl>
</indent>

<nl><paragraph>
There is some doubt in my mind about read notifications.  I am not sure I
want other people to know what I read.  I can see only two reasons
for this feature:<nl>
<indent>
 1) as a form of "proof of delivery".  Some email systems provide
this, but I don't like it.<nl>
 2) as a means of collective revenue (pay-per-read)<nl>
</indent>

<nl><paragraph>
As for charging, fairness requires that the link not be activated
until I have seen a warning (otherwise I might get charged a zillion
dollars to read the document - just like 900 phone numbers in the
USA).  So this will add complexity to the client.

<nl><paragraph>
Also, attention links are not sufficient for a charging.  They
support a model where I am charged once per read, no matter how much
of the document I read.  But it seems likely that there might be need
for other charging models.  It is also unclear that they are technically
sufficient.  For economic purposes, you would want the message to be sent
by the server, not the client.  But this would cease working if the
document were copied.  (But maybe this is not a fair objection, since
I know of no scheme that can preserve property rights given the
possibility of perfect digital  copying.)

<nl><paragraph>
Continuing on the more general question of read notification,
regardless of purpose, it is possible that one might desire
notification on a finer grain that the entire document.  But this, I
think, requires the cooperation of the client.  Indeed, the client
can tell the server that a given piece of text has been displayed,
but not whether the user actually read it (unless we go further, and
implement it with an executable function which requires the user to
click on a button)

<nl><paragraph>
As for the second form (modification notification), it seems to me
that there is a need to inform not just the owner, but also other
people.  There are two reasons for this:

<nl><paragraph>
First, as owner of a document, I am not likely to allow other people
to modify my document at all.  On the other hand, I might be
interested in notifications when someone adds or deletes a link <bold>to</bold>
my document.  But attention links don't address this problem.

<nl><paragraph>
Second, as a reader of a document I don't own, I might want to be
notified when the owner modifies it, since I might wish to re-read it
(or at least the changed sections.)  Let's call these "monitor"
links.  Monitor links might be a useful means of reducing effort
required for some kinds of network retrievals - those where I am
interested in new developments in certain areas.  Now, instead of
polling documents to see whether they've changed, I can just leave an
"attention link" and get a notification.

<nl><paragraph>
On the other hand, this has some problems.  One of them is the
question of who pays the cost of sending all these notifications.
Can you imagine the load on your workstation as it sends out 10,000
monitor notifications?  Perhaps this can be answered by bringing in
more economics - that is, to attach a monitor link I need to set up
an account such that I can be charged for the delivery.  Or maybe the
notifications are sent by the document server, so as an author I am
not affected.

<nl><paragraph>
A second problem (or at least issue) is that monitor links require
finer grain of size and time.  Some users will want to monitor only
select portions of a document.  Likewise, we may not want
notifications sent when <italic>any</italic> editing is made, but
rather only when the author completes a session.  That is, if I edit
the document for a day, saving changes six times, you don't want six
notifications.  This might require some notion of "transactions" such
as used in data bases.

<nl><paragraph>
Finally though, I don't think it is correct to call these things
links.  They are not related to logical structure, nor are they
explicitly activated by the reader (or writer), indeed that person
not even be aware that it was activated.  Consider the more general
question - if attention links are a subcase of execution links, and
attention links can be activated without knowledge of the user,
should all  execution links be capable of such activation?  Do you
want to read documents which can cause arbitrary computations to
occur without your choice, or even knowledge?